<HTML>
<CENTER><A HREF = "http://lammps.sandia.gov">LAMMPS WWW Site</A> - <A HREF = "Manual.html">LAMMPS Documentation</A> - <A HREF = "Section_commands.html#comm">LAMMPS Commands</A> 
</CENTER>






<HR>

<H3>read_restart command 
</H3>
<P><B>Syntax:</B>
</P>
<PRE>read_restart file 
</PRE>
<UL><LI>file = name of binary restart file to read in 
</UL>
<P><B>Examples:</B>
</P>
<PRE>read_restart save.10000
read_restart restart.*
read_restart poly.*.% 
</PRE>
<PRE>
</PRE>
<P><B>Description:</B>
</P>
<P>Read in a previously saved simulation from a restart file.  This
allows continuation of a previous run.  Information about what is
stored in a restart file is given below.
</P>
<P>Restart files are saved in binary format to enable exact restarts,
meaning that the trajectories of a restarted run will precisely match
those produced by the original run had it continued on.
</P>
<P>Several things can prevent exact restarts due to round-off effects, in
which case the trajectories in the 2 runs will slowly diverge.  These
include running on a different number of processors or changing
certain settings such as those set by the <A HREF = "newton.html">newton</A> or
<A HREF = "processors.html">processors</A> commands.  LAMMPS will issue a warning in
these cases.
</P>
<P>Certain fixes will not restart exactly, though they should provide
statistically similar results.  These include <A HREF = "fix_shake.html">fix
shake</A> and <A HREF = "fix_langevin.html">fix langevin</A>.
</P>
<P>Certain pair styles will not restart exactly, though they should
provide statistically similar results.  This is because the forces
they compute depend on atom velocities, which are used at half-step
values every timestep when forces are computed.  When a run restarts,
forces are initially evaluated with a full-step velocity, which is
different than if the run had continued.  These pair styles include
<A HREF = "pair_gran.html">granular pair styles</A>, <A HREF = "pair_dpd.html">pair dpd</A>, and
<A HREF = "pair_lubricate.html">pair lubricate</A>.
</P>
<P>If a restarted run is immediately different than the run which
produced the restart file, it could be a LAMMPS bug, so consider
<A HREF = "Section_errors.html#err_2">reporting it</A> if you think the behavior is
wrong.
</P>
<P>Because restart files are binary, they may not be portable to other
machines.  They can be converted to ASCII data files using the
<A HREF = "Section_tools.html#restart">restart2data tool</A> in the tools
sub-directory of the LAMMPS distribution.
</P>
<P>Similar to how restart files are written (see the
<A HREF = "write_restart.html">write_restart</A> and <A HREF = "restart.html">restart</A>
commands), the restart filename can contain two wild-card characters.
If a "*" appears in the filename, the directory is searched for all
filenames that match the pattern where "*" is replaced with a timestep
value.  The file with the largest timestep value is read in.  Thus,
this effectively means, read the latest restart file.  It's useful if
you want your script to continue a run from where it left off.  See
the <A HREF = "run.html">run</A> command and its "upto" option for how to specify
the run command so it doesn't need to be changed either.
</P>
<P>If a "%" character appears in the restart filename, LAMMPS expects a
set of multiple files to exist.  The <A HREF = "restart.html">restart</A> and
<A HREF = "write_restart.html">write_restart</A> commands explain how such sets are
created.  Read_restart will first read a filename where "%" is
replaced by "base".  This file tells LAMMPS how many processors
created the set.  Read_restart then reads the additional files.  For
example, if the restart file was specified as save.% when it was
written, then read_restart reads the files save.base, save.0, save.1,
... save.P-1, where P is the number of processors that created the
restart file.  The processors in the current LAMMPS simulation share
the work of reading these files; each reads a roughly equal subset of
the files.  The number of processors which created the set can be
different the number of processors in the current LAMMPS simulation.
This can be a fast mode of input on parallel machines that support
parallel I/O.
</P>
<HR>

<P>A restart file stores the following information about a simulation:
units and atom style, simulation box size and shape and boundary
settings, group definitions, per-type atom settings such as mass,
per-atom attributes including their group assignments and molecular
topology attributes, force field styles and coefficients, and
<A HREF = "special_bonds.html">special_bonds</A> settings.  This means that commands
for these quantities do not need to be re-specified in the input
script that reads the restart file, though you can redefine settings
after the restart file is read.
</P>
<P>One exception is that some pair styles do not store their info in
restart files.  The doc pages for individual pair styles note if this
is the case.  This is also true of bond_style hybrid (and angle_style,
dihedral_style, improper_style hybrid).
</P>
<P>All settings made by the <A HREF = "pair_modify.html">pair_modify</A> command,
such as the shift and tail settings, are stored in the restart file
with the pair style.  The one exception is the <A HREF = "pair_modify.html">pair_modify
compute</A> setting is not stored.
</P>
<P>Information about <A HREF = "kspace_style.html">kspace_style</A> settings are not
stored in the restart file.  Hence if you wish to use an Ewald or PPPM
solver, these commands must be re-issued after the restart file is
read.
</P>
<P>The list of <A HREF = "fix.html">fixes</A> used for a simulation is not stored in
the restart file.  This means the new input script should specify all
fixes it will use.  Note that some fixes store an internal "state"
which is written to the restart file.  This allows the fix to continue
on with its calculations in a restarted simulation.  To re-enable such
a fix, the fix command in the new input script must use the same
fix-ID and group-ID as was used in the input script that wrote the
restart file.  If a match is found, LAMMPS prints a message indicating
that the fix is being re-enabled.  If no match is found before the
first run or minimization is performed by the new script, the "state"
information for the saved fix is discarded.  See the doc pages for
individual fixes for info on which ones can be restarted in this
manner.
</P>
<P>Bond interactions (angle, etc) that have been turned off by the <A HREF = "fix_shake.html">fix
shake</A> or <A HREF = "delete_bonds.html">delete_bonds</A> command will
be written to a restart file as if they are turned on.  This means
they will need to be turned off again in a new run after the restart
file is read.
</P>
<P>Bonds that are broken (e.g. by a bond-breaking potential) are written
to the restart file as broken bonds with a type of 0.  Thus these
bonds will still be broken when the restart file is read.
</P>
<P>IMPORTANT NOTE: No other information is stored in the restart file.
This means that an input script that reads a restart file should
specify settings for quantities like <A HREF = "timestep.html">timestep size</A>,
<A HREF = "thermo_style.html">thermodynamic</A>, <A HREF = "neighbor.html">neighbor list</A>
criteria including settings made via the
<A HREF = "neigh_modify.html">neigh_modify</A> comand, <A HREF = "dump.html">dump</A> file
output, <A HREF = "region.html">geometric regions</A>, etc.
</P>
<HR>

<P><B>Restrictions:</B> none
</P>
<P><B>Related commands:</B>
</P>
<P><A HREF = "read_data.html">read_data</A>, <A HREF = "read_dump.html">read_dump</A>,
<A HREF = "write_restart.html">write_restart</A>, <A HREF = "restart.html">restart</A>
</P>
<P><B>Default:</B> none
</P>
</HTML>
